This invention relates, generally, to telecommunication intelligent and advance intelligent networks and, in particular, to a methodology for collecting data in such networks based on propagation of a test call message incorporating a travelling log through the network.
It is noted that general references made herein to "intelligent network" or "IN" is intended to specifically cover intelligent networks (INs) and advance intelligent networks (AINs), as it will be apparent to those skilled in the art that the present invention is equally applicable to both IN and AIN testing.
An IN based service offering requires cooperation between many different network elements (NEs) and network systems (NSs), which typically include service switching points (SSPs), Intelligent Peripheral (IPs), Mediation Points (MPs), Signaling Transfer Points (STPs), Adjuncts, and service control points (SCPs) that communicate using a common channel signaling number 7 (CCS7) network protocol. The main objective of intelligent network testing is to trouble-shoot the implementation of the SSP, IP, Adjunct, STP, MP, and SCP relevant service specifications, to ensure that they can operate harmoniously. Trouble-shooting in an operational environment where multiple network elements (e.g., SSPs, IPs, Adjuncts, MPs, SCPs) and a signaling system number 7 (SS7) network, which includes signaling transfer points (STPs) and links, are required to set up connections between elements, presently requires either manual operations or external operations systems (OSs) to analyze and correlate the event/alert messages at the various elements in the network. Manual operations are not practical. External OSs may not be available.
When customers report trouble, or the network surveillance processes and OSs detect problems in the network, a tester or maintenance personnel uses the local SSP maintenance capabilities to both verify and isolate these problems, and then check that they have been repaired. The SSP maintenance capabilities may include a capability to check the IN call routing and translation, a capability to access and display trigger information and status, as well as the notification (event/alert) messages and measurements. These capabilities can be used to determine the source of the problem, be it in the SSP or outside the SSP which may be in the signaling network, a remote SCP, mediation points (MPs), an intelligent peripheral (IP), adjunct, or in any other element in the network.
In North America, Bell Communication Research (Bellcore) AIN SSP generic specifications [1] TR-NWT-001284, Advanced Intelligent Network (AIN) 0.1 Switching Systems Generic Requirements, Bellcore Technical Reference, Issue 1, August 1992 and [2] GR-1298-CORE, Advanced Intelligent Network (AIN) 0.2 Switching Systems Generic Requirements, Bellcore, Issue 2, December 1994, both of which hereby are incorporated herein by reference, provided tools for network testing which include a message format with an AIN maintenance parameter (AMP) and a call history log (C-Log). A test call message having its AMP set is launched from a SSP by a tester. As the message propagates through the network, any SSP or SCP along the test call message route recognizes the AMP parameter, and activates the collection of data and messages related to this call. This information is stored in the C-Log which is local to the particular network element. The tester is required to log onto each element (SSPs and SCPs) along this path and retrieve the specific C-Log relevant to this test call. This process is time consuming and complex for network maintenance and operations.
Further, in a multi-vendor Network Elements (NEs) and Network Systems (NSs) operations environment, it is difficult to determine the signaling network configuration and routing of CCS7 messages for specific subsystems. Maintenance personnel often have to rely on information given by the customer to determine the network configuration, before they start trouble-shooting the network. Capturing specific messages by setting a trap on the SSP for IN events and messages in a live environment is difficult because multiple messages from other calls and queries are typically coming in. This shortcoming could create the laborious task of checking the Datafill at various sites in the routing message for various multi-vendor network elements (NEs) and network systems (NSs).
Therefore, there is an apparent need for better methodologies to effect testing of intelligent networks.